Telephone lines and other communication links have been used for many years to establish remote access to a computer system. Modems on either end of the line convert computer data into signals suitable for transmission over the conventional telephone lines. A remote session is initiated by dialling the remote modem. After a telephone link has been established, both modems engage in an initial data exchange (a `training period`) to establish various communication parameters. This training period may take up to 30 seconds to complete. Thereafter, the remote user has direct access to the computer system and can interact with it in a known manner. The low speed of communication over a conventional telephone link prevents the use of graphical applications, but text-based terminal programs can be run with acceptable performance. Examples of programs used for remote logins are `Telnet` and `tn3270`, which rely on a previous process (such as the known process SLIPDIAL) to establish the connection as described above. Other known applications provide both the call initialisation and closedown as well as the remote terminal application (for example, IBM's PASSPORT or PROCOMM's PCPLUS).
The telephone connection is required throughout the communication session, even while both computer systems are idle, for example while waiting for input from the user.
Many solutions have been proposed in the past to make the use of the expensive telephone links more efficient. Batch processing is widely used for this purpose: instead of running applications on-line, data is bulk transmitted and applications run locally without actually being connected. Popular e-mail application programs such as `Remote WinMail` and `cc:Mail` allow users to compose e-mail messages without requiring connectivity. The actual sending of the message (for which a telephone connection will be established automatically) may be scheduled based on telephone tariffs or the importance of the mail message.
Hence, remote data access over telephone connections is possible by either:
establishing a single telephone connection throughout the session and then using conventional applications, or PA1 establishing brief but frequent telephone connections to exchange data and then using customised applications for batch-processing. PA1 one or more call handlers; and PA1 a call manager for receiving communication calls generated by applications on a computer system on which the call manager is installed, the call manager including means for analyzing these communication calls to identify their origin and means for redirecting identified communication calls to a call handler component for further processing; PA1 wherein the call handler component is adapted to transmit the communication call to its target destination using a preferred protocol.
The latter approach is generally less costly. However, applications for batch-processing often require unfamiliar and difficult user interaction patterns. There is a need for a system which offers the benefits of real connection-oriented applications without the cost and inconvenience of having to be attached by a permanent telephone connection.
Telephone tariffs of wired networks are sufficiently prohibitive that they restrict usage of network communication applications, but mobile communication links (wireless connections) are generally far slower and more expensive than fixed-wire communication links and so this problem is much more critical in a mobile environment. Conventional network communication applications such as telnet, file transfer protocol (ftp) or `sendmail`, and the conventional protocols that they use (such as the widely used TCP/IP suite of protocols), are written to operate on top of relatively fast, reliable and cheap wired network connections and are not optimised for the mobile environment. They typically either fail completely or perform badly due to the alien line characteristics of the mobile data links.
For example, TCP/IP does not distinguish between the loss of a data packet and a transmission error--both are interpreted as a sign of network congestion, and TCP/IP reacts by applying an exponential back-off algorithm and reducing throughput. On mobile data links, however, a lost data packet is much more likely to be caused by a fading mobile link or excessive bit error rates during transmission. Forward error correction would correct these, but TCP/IP increases the wait time and then reduces the passage transmission rate (reducing the number of currently open packets). This will do nothing to solve the problem and will further degrade the user-perceived link quality by introducing artificial time delays. Alternative methods and algorithms more suitable for mobile data links are readily available, but are not easily combined with TCP/IP.
Furthermore, TCP/IP is unable to take advantage of the point-to-point nature of mobile data links such as GSM channels. In the multi-user environment that TCP/IP was designed for, each packet requires extensive headers to allow routing, assignment to individual logical connection, and to reassemble the packets at the remote side. On point-to-point links, most of these headers are redundant.
Routing in TCP/IP is based on static and hierarchical IP addresses; this causes problems if mobile hosts connect to the network at different access points and do not want to change their IP addresses.
Specialised applications can be written which can support the same functionality as telnet, ftp or sendmail in a mobile environment with adequate performance, but there are a number of reasons why conventional applications should be used instead. Firstly, mobile applications often require unfamiliar and difficult user interaction patterns. Many computer operators learn only a small set of applications and are reluctant to adopt new designs, especially where the new design duplicates and is required to be used alongside the old design. Secondly, conventional network communication applications are widely available and readily installed on many computer systems and it is desirable to make full use of these existing resources. Furthermore, adapting applications for wireless links typically involves very specific modifications which cannot be abstracted and re-used with other applications, and so the effort has to be repeated for each application.
There is a need to enable conventional network applications to work efficiently in a mobile environment while avoiding the need for new mobile-aware applications. There is also a need to manage data communications in a manner which achieves efficient use of conventional network applications without reliance on permanent connections throughout a communication session even when not in a mobile environment.